Mobile terminals—such as mobile telephones, laptops, PDAs, BlackBerry® devices—are generally equipped with a certain number of functionalities allowing for example to check e-mails (MAIL), to open an instant messaging session (IM), or to communicate on a blog (BLOG). Each of these functionalities is implemented by a specific computer application which is integrated in the mobile terminal.
FIG. 1 shows various screenshots of a screen of a mobile terminal TM upon activation of these functionalities. Initially, the screen displays the various functionalities (IM, MAIL, BLOG or other) in the form of strips, icons, rolling menus, etc. The user can select the desired functionality by means of the navigation keys on his keypad.
In the case where the user selects the instant messaging function (IM), a specific computer application (AIM®, ICQ®, Windows Live Messenger®, Yahoo!®, Messenger®, etc.) is launched so that the mobile terminal TM can connect to an instant messaging server IM (Microsoft Live Communication Server®, Sun Java System Instant Messaging®, Jabberd®, Groupwise Messenger®, etc.) and can use the instant messaging services traditionally offered: conversation Svc1, contact list management Svc2, rule management Svc3, etc. These services Svc1, Svc2, Svc3 are displayed on the screen of the mobile terminal TM in the form of strips, icons, rolling menus, etc. The user can then select the desired service by means of the navigation keys on his keypad.
By way of example, when the user actuates the conversation service Svc1, the server IM sends to the mobile terminal TM the user's contact list (or “buddy list”), said list being displayed on the screen of said terminal.
In the case where the user selects the e-mail function (MAIL), a new specific computer application (Google Mail®, SFR Mail®, Orange Mail®, Outlook®, etc.) is launched so that the mobile terminal TM can connect to a MAIL server (SendMail®, Zimbra®, Lotus®, Microsoft Exchange Server®, etc.) and can use the e-mail services traditionally offered: receive/send e-mail Svc1, address book management Svc2, message rules Svc3, etc. These services are displayed on the screen of the mobile terminal TM in the same way as for the IM function described above.
By way of example, when the user actuates the receive/send e-mail service Svc1, the server MAIL sends to the mobile terminal TM the user's inbox, the list of e-mails being displayed on the screen of said terminal.
It will be understood that a similar mode of operation is implemented when the user selects the BLOG function or another function.
The computer applications which allow to launch the functions IM, MAIL, BLOG or others are specific programs which have different lines of code depending on the functionality. Thus, the greater the number of functionalities offered, the more the mobile terminal will have to integrate different computer applications capable of implementing them. This situation is a disadvantage not only for developers (cumbersome programming which takes a lot of time and effort), but also for users (the greater the number of functionalities offered, the higher the price of the mobile terminal).
FIG. 2 schematically shows a communication network which is customarily used in mobile telephony but which also applies to other similar mobile terminals TM.
As soon as the user selects a functionality IM, MAIL, BLOG or other and launches the associated computer application, his mobile terminal TM connects to the corresponding source server SS1, SS2, SS3, SS4. All the information exchanged between the mobile terminal TM and the source servers SS1, SS2, SS3, SS4 passes through dedicated information channels, respectively Ci1, Ci2, Ci3 or Ci4.
The information passes through these information channels according to specific protocols (HTTP, IP, SMTP, etc.) which define the rules of communication between the mobile terminals TM and the source servers SS1, SS2, SS3 or SS4. The source servers and the mobile terminals must be able to exchange their information on the basis of a common language (or common format) such as: HTML, XML, etc. Since the nature of the information exchanged between the mobile terminal and the source servers may vary, said mobile terminal must be capable of implementing the different protocols so as to “understand” the information that it receives and to display said information on its screen in a manner that is intelligible for the user. Likewise, the source servers SS1, SS2, SS3 or SS4 must be capable of understanding the requests transmitted by the mobile terminal TM so as to be able to process them correctly.
The communication networks known in the art are therefore complex since they multiply the number of information channels between the mobile terminal and the various source servers, and also the number of communication protocols allowing the exchange of information in said channels. This latter aspect is a particular constraint for developers and operators, since many lines of code have to be integrated in the mobile terminals and the source servers.
In order to overcome this disadvantage, communication networks are known in which all the information/requests transmitted to/by the mobile terminal TM are in a single target format. In this way, it is sufficient for the mobile terminal TM to integrate only the communication protocol compatible with this target format in order to “understand” the information that it receives and to display said information on its screen in a manner that is intelligible for the user.
However, the source servers SS1, SS2, SS3, SS4 store their information in source formats that are specific to them. Generally, this information is in the form of a succession of lines of code which are incomprehensible to the user. It is therefore necessary to manage the format of the information transmitted by the source servers SS1, SS2, SS3, SS4 so that said information can be understood by the mobile terminal TM and the user.
Likewise, when the mobile terminal TM transmits requests to the source servers SS1, SS2, SS3, SS4, said requests are in the target format. It is therefore necessary to manage the format of the requests received by the source servers SS1, SS2, SS3, SS4 so that said requests can be processed by the latter.
In order to manage these different formats, the source servers must therefore be designed to convert:
to the target format the information that they transmit to the mobile terminal;
to the source format the requests that they receive from the mobile terminal.
Although effective, these computer applications which allow to manage formats are complex to implement, all the more so since they can vary depending on the source servers. Moreover, these computer applications may need to evolve to take account of the new source formats and/or target formats used in the communication networks. As a result, the integrations and/or modifications of these computer applications are long and expensive for the operators, since a large number of management protocols and software/hardware items have to be taken into account.
Thus, there remains a need to address the aforementioned drawbacks, and to improve current methods and systems.